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(57) Le proc^d^ utilise un reseau de communication 
ouvert (10) sur lequel sont connect^s des postes serveurs 
de marchands (20) et des postes clients (30) et comprend: 
Telaboration par un poste serveur de marchand d'un 
ticket de paiement, concemant un achat envisage entre le 
marchand et un client, et comportant des informations 
relatives au marchand, au client, k I'objet de I'achat et a 
son prix; la transmission du ticket de paiement via le 
reseau a un poste serveur de paiement (40); la 
verification automatique par le serveur de paiement si le 
paiement du prix est autoris^ pour le client conceme, soit 
par interrogation d'un compte client propre au client. 



(57) A method using an open communication network 
(10) to which retailer server stations (20) and customer 
stations (30) are connected. According to the method, a 
retailer server station generates a payment slip for the 
planned purchase transaction between the retailer and a 
customer, which slip comprises data on the retailer, the 
customer, the purchased item or service and the price; the 
payment slip is transmitted over the network to a 
payment server station (40); the payment server 
automatically checks whether the payment of said price 
is authorised for the customer in question, by querying 
the client's personal account set up in the payment server 
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tenu par le serveur de paiement, et destine au paiement 
des petits montanls, soil par interrogation sur un reseau 
bancaire (50) independant du reseau informatique (10), 
pour les paiements de montants plus eleves; si la 
verification est positive, Telaboration par le serveur de 
paiement d'un bon de caisse comportant au moins une 
partie des informations du ticket de paiement; et la 
transmission du bon de caisse au serveur de march and 
afm d'autoriser la realisation de 1' achat. 



for paying small amounts, or, in the case of larger 
amounts, by making a query over a banking network (50) 
separate from the computer network (10); if the payment 
is authorised, the payment server generates a cash 
voucher comprising at least some of the data on the 
payment slip; and the cash voucher is transmitted to the 
retailer to enable the purchase to go ahead. 
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5 

The method uses a public communication network (10), to which are 
connected supplier servers (20) and customer stations (30) and comprises: 

- development by a supplier server of a payment ticket, concerning a 
purchase envisaged between the supplier and a customer, and comprising 

10 information relating to the supplier, the customer, the purchase object and the 
price, 

- transmission of the payment ticket via the computer network to a 
payment server (40), 

- automatic verification by the payment server if the payment of the price 
15 is authorised for the customer, either by interrogation of a customer accotmt of the 

customer, held by the payment server and intended for payment of small sums, or 
by interrogadon on a banking network (50) independent of the computer network 
(10), for payment of higher sums, 

- if the verification is positive, development by the payment server of a 
20 voucher including at least a part of the payment ticket information, and 

- transmission of the voucher to the supplier server so as to authorise the 
conclusion of the purchase. 

Figure 1. 

25 
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ELECTKONIC PAYMENT METHOD FOR PURCHASE-REIATED TRANSACTIONS OVER A 
COMPUTER NETWORK 

The present invention concerns an electronic payment method enabling 
5 transactions to be carried out relating to the purchase of "goods" offered by 
suppliers by means of on-line services via a public computer telecommunication 
network to which are attached suppliers* servers and clients' stations. Here, "public 
computer telecommunication network" is intended to mean a network to which 
persons or companies can freely connect themselves so long as they have an 

10 address, for example the "Intemet". "Goods" is intended to mean products or 
services, which are delivered outside the network after the transaction has been 
concluded, as well as non-material goods, such as information, which can be 
delivered via the computer network. 

Various electronic payment methods have been proposed, and some are 

15 already operational. 

Several methods are based on a new form of currency. They involve an 
electronic representation, sometimes called a "token", which can be purely 
embodied in software or can be partly physical, for example a "smart card". These 
methods necessitate circulation of the currency on the computer network, which 

20 presents difficult security problems regarding the creation of false currency. 

Other known electronic payment methods necessitate a direct relation with 
a bank or a banking network. These are typified by methods used in the credit 
card networks such as well-known methods utilizing point-of-sale terminals 
linked to a bank card circuit as well as methods employing electronic cheques 

25 using an electronic signature to authenticate the purchaser. This is a form of 
engagement letter issued by a purchaser, returned to the seller and accepted and 
recognised by a bank. 

There are certain inconveniences associated with methods which 
necessitate, at one time or another during a transaction, a relationship with a 

30 traditional banking system and the effecting of a transaction in such a system. 
Banking system transactions have a real cost which becomes prohibitive when the 
amount of the purchase is very low, for example, an amount based on a query to a 
data base. And computer networks are well adapted to the sale of low-priced 
goods, in particular informational goods, since the delivery can be carried out 

35 through the network itself. Moreover, access to a banking network or a bank card 
network must have high levels of security, which, in practical terms, excludes the 
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possibility of access through a public computer network, such as the "Internet", to 
wtuch potential purchasers can connect themselves. 

An object of the invention is to provide a method which avoids the 
problems of the known methods - in particular, a method permitting a simple and 
5 reliable way of accomplishing transactions relating to the purchase of goods on a 
computer network, without the need to circulate electronic currency, for goods of 
high price requiring authorisation from a traditional banking system, as well as for 
goods of low to very-low price. 

The object is achieved by a method of the type defined at the beginning of 
10 the present description and comprising, according to the invention, the steps of: 

-creation, by the server of a supplier connected to the network, of a 
transaction authorisation request or "payment ticket", concerning a purchase 
envisaged between the supplier and a customer, and comprising information 
relating to the supplier, the customer, the purchased object and the price; 
15 -transmission of the payment ticket via the computer network to a payment 

server which is distinct from the customer station and the supplier server, 

-automatic verification by the payment server of whether the payment of 
the price is authorised for the customer involved, the verification being effected, 
according to the level of the price to be paid, either by interrogation of an account 
20 of the customer, held by the payment server and intended for payment of smaller 
sums, or by interrogation on a banking network, independent of the computer 
network, for payment of higher sums; 

-if the verification is positive, creation by the payment server of a 
transaction authorisation or voucher including at least part of the payment ticket 
25 information; and 

-transmission of the voucher to the supplier server via the computer 
network, to authorise the conclusion of the purchase. 

Thus, the procedure according to the invention is noteworthy in that it 
necessitates neither the creation of electronic currency nor the circulation of 
30 } electronic currency over the computer network. 

The control of the transactions is effected by a payment server which alone 
can access a banking network or a bank card network, and which manages non- 
barik customer accounts firom which small sum transactions can be effected. 

The payment server also manages non-bank supplier accounts used for 
35 small sum transactions. In this way, when a voucher is transmitted after 
verification by interrogation of a customer account held by the payment server, the 
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cimount of the purchase is debited from the customer account and credited to the 
account of the concerned supplier and held by the payment server, a procedure 
which does not produce high processing costs. 

Each customer has available his own identity to enable use of the payment 
method. He must also have available a real bank account, preferably one which 
can be operated by means of traditional bank cards. The verification by the 
payment server can include a preliminary phase of validating the identity of the 
customer from the contents of the payment ticket. The identity validation precedes 
access to the customer account (if the sum of the purchase is low) or access to the 
bank network (if the amount involved in the purchase is higher). The payment 
server preferably includes means, for example a data base, for storing the 
relationship between the customer identities used for transactions on the computer 
network and the bank identities (bank account or credit card numbers) used for 
transactions on the bank network. In that way, the circulation of banking identities 
on the computer network can be avoided. 

An implementation of the invention will now be described, as a non- 
limiting example, with reference to the accompanying drawings, in which: 

-Figure 1 is a general schematic view of an electronic payment system 
according to the invention; 

-Figure 2 is a representation in the form of a block schematic diagram of a 
payment server of the system of Figure 1; 

-Figure 3 illustrates the progression of operations relating to a purchase 
using the system of Figure 1; and 

Figures 4A to 4C are flow charts showing schematically the operations 
carried out by the payment server. 

Figure 1 represents schematically a computer telecommunication network 
10 to which are connected supplier servers 20, customer stations 30 and at least 
one payment server 40. 

The computer network 10 is an open or public network, for example the 
network known as the "Internet". The supplier servers 20 are units such as those 
currently used for on-line services connected to the Internet, for example, units 
organised around UNIX-based multi-processor machines. The customer stations 
30 arc basically microcomputers which are provided with means for connecting to 
th Intemet network 10, for example, in the form of a "Web" interface. The 
supplier servers 20 and the customer stations 30 may use, for example, known 
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software protocols commonly known as the "World Wide Web" ("WWW") 
employing the HTTP protocol. 

The payment server 40, shown in more detail in Figure 2, comprises front 
and rear units respectively 41 and 42 both connected to the Internet 10. The front 
5 unit 41 has an architecture similar to that of a standard server connected to a 
network such as the Intemet. The rear unit 42 includes a processing unit 43 
containing one or more processors, a data base 44 containing information relating 
to the suppliers and customers subscribing to the payment system, a transaction 
register 45, an interface unit 46 for coimecting with a banking network or with a 

10 bank card network 50, and a communication bus 47 or similar other link enabling 
connection between the different constituent parts of the imit. A secure cormection 
48 enables bi-directional communication between the front unit 41 and the 
processing unit 43. Communication with the network 10 is controlled by the front 
unit 41 while management of the data base 44 as well as the control of the 

15 communication with the banking network are assured by the rear unit 42. 

The data base 44 contains information relating to the customers and to the 
suppliers who have subscribed to the payment system. For each customer, the data 
base 44 contains the system identity ("CId") assigned when the customer initially 
subscribes to the system, a customer account or electronic wallet ("PME") for 

20 payment of small sums, a banking identity such as an account number of a real 
account or a credit card number, possibly as well as the customer's own access 
password or "key". For each supplier, the data base 44 contains the system identity 
of the supplier/merchant ("Mid"), which is assigned when the supplier mitially 
subscribes to the system, a supplier account, or electronic cash register ("TCE") for 

25 receipt of small sums and a banking identity such as a bank account number. 

Figure 3 shows schematically the different stages of a transaction relating 
to the purchase of goods by a subscribing customer from a subscribing supplier. It 
can be a case of material goods, for which delivery to the customer will take place 
after conclusion of the transaction, or non-material goods (such as information) 

30 which can be provided to the customer over the computer network as soon as 
electronic payment has been effected. 

(\^ Consultation by the customer 

After cormecting to the Internet 10, a customer can consult the catalogue or 
"window" of any supplier on-line by accessing the supplier's server 20 and 
35 viewing the supplier's wares on the screen of the customer station 30. On 
presentation of the customer's system identity Od, the supplier's server 20 can 
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present to the customer particular financial conditions (for example a discount) 
applicable tp the potential transaction. 
(2) Purchase demand 

Once the customer has chosen a commodity (object) O, his choice is 
5 transmitted to the supplier's server in the form of a message containing an identity 
Old of the commodity and the identity dd of the customer. When necessary, for 
example, for the eventual delivery of the commodity chosen, the supplier's server 
can request supplementary information such as an address and preferred delivery 
time. This may conveniently be done through use of an electronic form sent over 
10 the network to be filled in by the customer. 

When the purchase envisaged represents a large sum or is subjected to legal 
conditions, a preliminary authentication of the customer may be desired. As will 
be seen in detail in the following, the authentication of a customer is effected by 
the payment server 40. Also, the authentication demand coming from a supplier is 
15 advantageously issued in the form of a payment ticket of no value which is 
transmitted to the payment server over the computer network via the customer 
station and, in the case of positive authentication, provokes the return of a voucher 
from the payment server to the supplier server, always by way of the customer 
station. The procedure for the establishment of a payment ticket and for the 
20 returning of a voucher are described in greater detail in the following. 

The purchase demand issued by the customer can relate to a single 
commodity or to several goods to be provided as a group "basket purchase". 
(3^ Development of the payment demand 

In response to a purchase demand, the supplier server develops a payment 
25 demand, which can include the following information: 
-Identity of the supplier ("Mid"); 

-Description of the conunodity ordered, or, in the case of grouped 
purchases, each of the goods in the basket; 
-Type of transaction (single or basket); 
30 -Identity of the customer ("CId"); 

-Identity of the commodity or collection of goods of the basket ("Old"); 
-Price of the conunodity ("Oid"); 
-Value Added Tax, VAT, (if applicable), 

-Date and time of the issue of the payment ticket (hour and date stamping 
35 by the supplier server); 

-Period of validity of the payment ticket; and 
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-Serial number in the sales register of the supplier (particularly in the case 
when the transaction has included a preliminary authentication stage). 
TTie combination of the above information is coded as a series of bytes 
which are contained in the hidden channel of a payment ticket (or URL of an order 
5 of a commodity, URL being the initials of "Unifomi Resource Locator" used in 
WWW software with the HTTP protocol), as follows: 

URL http:<SP><description of the order>, 
where SP is the Internet address of the payment server. The payment ticket is 
addressed to the customer station* It is completed by two logical "anchors" which 
10 enable the customer either to cancel or to confirm. 
(4) Sending the payment order 

The payment order is transmitted to the payment server simply by 
validation by the customer of the URL of the payment order. As will be 
appreciated, the payment ticket only passes in transit through the customer station. 

15 (5) Issue of the voucher 

Upon reception of a payment order, the payment server 40 decodes the 
payment order, authenticates the customer and investigates whether the payment 
can be authorised before returning either a voucher or a payment refusal. The 
customer authentication and payment authorisation operations will be described in 

20 greater detail with reference to Figure 4. 

When the verification process does not permit authorisation of payment, an 
explanatory refusal notification (referring, for example, to insufficient funds in the 
account, to the passing of a limit authorised for the customer, etc.) is sent to the 
customer by the payment server. When the verification does permit authorisation 

25 of payment, the information contained in the payment ticket is completed with a 
serial number in the transaction register 45, a time stamp, a validity time limit 
(typically some tens of seconds) and the seal of the payment server constituting 
certification information. The combination of this information, possibly after 
being digitally signed through use of a private key portion of a public key/private 

30 key encryption system belonging to the payment server (which ensures the validity 
and the integrity of the payment authorisation) is encoded in a series of bytes 
which constitute the hidden channel of a voucher or delivery URL: 

URL http:<M><description of the voucher>, 
where M is the Internet address of the supplier. 

35 (6) Delivcrv request 
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The voucher is transmitted to the supplier server via the customer station. 
This can be effected automatically by the software installed in the customer station 
using the re-routing possibility of the URLs, well-known to those skilled in the art 
to which the invention pertains. The supplier server decodes and verifies the 
5 received voucher before authorising delivery of the conmiodity. TTiis verification 
includes using the private key of the payment server, verifying that the validity 
time limit has not passed and comparing the contents of the voucher with the 
payment demand. 

(7) Delivery of the commoditv 

10 When the voucher has been validated by the supplier server, this server can 

effect delivery directly to the customer station, in the case where the commodity 
being purchased is information, or address to the customer station a document 
permitting the collection of the commodity and, notably, specifying the place of 
delivery and the name of the recipient. 

IS It will be noted that, in the case of a grouped or basket purchase, the 

supplier server creates an object with allocation of a unique identity, a list of the 
URLs of each of the goods contained in the basket. It is this object which is 
indicated in the URL commodity order and which enables the details of the 
purchased goods to be recorded in the transaction register of the payment server. 

20 Figures 4A to 4C show the operations carried out by the payment server 40 

in response to the reception of a payment order. 

In the fi^ont unit 41(Figure 4A), the payment order is decoded (stage 61) 
and its validity is examined (test 62) notably from the point of view of the validity 
period. If the result of the examination is negative, a refusal notification is sent to 

25 the customer station (stage 63). If the result of the examination is positive, 
customer authentication follows (stage 64). The details of this operation are 
described further with reference to Figure 4C If the authentication is negative (test 
65), a refusal notification is sent to the customer (stage 63). If the authentication 
produces a positive result, the payment order (possibly limited to the customer 

30 identity CId, the supplier identity Mid and the price) is transmitted via the 
communication stage 68 to the rear unit 42 of the payment server shown in Rgure 
2 (stage 66). ITie connection 48, as mentioned above, is a secure cormection 
preventing access to the rear unit by persons coimected to the network 10. 

The front unit 41 then waits for the rear unit to determine whether or not to 

35 authorise the payment (stage 67). If the payment is not authorised, (test 68), a 
refusal notification is sent to the customer station (stage 63). If the payment is 
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authorised, a voucher is prepared (stage 69) using the information recorded in stage 
62. The voucher is saved in a memory of the front unit 41 (stage 70) and is sent to 
the supplier server via the customer station (stage 71). 

In the rear unit 42 (Figure 4B) of the payment server, a newly received and 
5 authenticated payment order is examined to determine whether this order should 
be authorised from the customer account PME or through the banking network. In 
this respect, the price is compared with a minimum threshold (test 72). This 
threshold is, for example, some tens of French francs. 

If the threshold is exceeded, a request for effecting the payment operation is 

10 sent to the banking network (stage 73) using the banking identity corresponding to 
the customer identity CId as obtained from consultation of the data base 44. The 
positive or negative response from the banking network (stage 74), when received, 
is transmitted to the front unit 41 (stage 75). 

If the threshold is not exceeded, the payment can be effected from the PME 

15 customer account. 

In this event, the customer account is examined to determine whether it has 
sufficient funds (test 76). If it does not, a refusal of payment authorisation is sent 
from the rear to the front unit (stage 75). If it does, the price is debited from the 
PME customer account, the TCE supplier account corresponding to the identity 

20 Mid is credited with the same sum (stage 77), the transaction is inscribed in the 
transaction register 45 (stage 78), and the payment authorisation - in other words, 
a positive response - is transmitted to the front unit 41 with the indication of the 
serial number of the inscription in the transaction register (stage 75). 

The authentication procedure in the payment server (Figure 4Q, at the 

25 stage 64 of Figure 4A, comprises sending to the customer station, preferably in 
secure (encrypted) form, a demand for an access key, or password (stage 641). 
Upon reception, in secure form, of the access key (stage 64), a comparison is 
effected between corresponding information contained in the data base 44 (test 
643). If the comparison is negative, and a maximum number of unsuccessful 

30 attempts has not been reached (test 644), the process returns to stage 641. If this 
maximum number has been reached, the failure to authorise is noted, and an alert 
is produced (stage 645) and a negative response is sent to the customer station 
(stage 646). The alert can comprise cancellation of the PME account or 
surveillance of this account in order to detect new usage attempts. If the test at 

35 step 643 is positive, the authentication is recorded (stage 647) and a positive 
response is provided (stage 648). 
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Different encoding techniques for permitting secure transmission of 
numeric information in a computer network are well known, notably for the 
request and sending of access keys. 

The authentication procedure disclosed herein permits a preliminary 
5 authentication of a customer to be effected when necessary before the 
establishment of a payment demand by the supplier's server. For this 
authentication, it is sufficient to create a payment ticket in which the price 
indicated is zero, as indicated above. 

The recording of the voucher m the front unit permits the customers and the 
10 suppliers to carry out controls and, possibly, to obtain copies of these. The 
recording of transactions in the rear unit enables records of the transactions to be 
conserved for possible use when needed later, for example, in the case of a dispute 
arising between a customer and a supplier. 

The balance in the customer accounts PME managed by the payment 
15 server is limited in size and, according to the preferred embodiment of the 
invention, these accounts do not receive interest payments (the payment system 
being separate from the banking world). Replenishment by a customer of his PME 
account can be effected from his bank account, by placing an order with his 
banking establishment. 
20 The supplier accounts TCE managed by the payment server are associated 

with real bank accounts of the suppliers, into which they are, for example, emptied 
daily. 

Although there has been described above one way of putting into effect the 
method according to the invention in an Internet environment and with WWW 

25 software using the HTTP protocol, a person skilled in the art will readily 
appreciate that the method can be put into effect with a network other than Intemet 
or further with supplier servers and customer station software which does not use 
the HTTP protocol of WWW. Furthermore, secure authentication methods usmg 
apparatus such as smart card readers or voiceprint recognition means can be 

30 foreseen in the place of access keys. These and other variations which will occur 
to those skilled in the art are within the spirit and scope of the present invention. 
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CLAIMS 

1. A method for effecting electronic payments for transactions relating to the 
purchase of goods offered by suppliers to customers via a public computer 
5 network, to which are connected supplier servers and customer stations^ 
characterised by the steps of: 

(a) development, by a supplier server connected to the network, of a 
transaction authorisation request, or payment ticket, concerning a purchase 
envisaged between the supplier and a customer, and comprising information 

10 relating to the supplier, the customer, the purchase object and the price, 

(b) transmission of the payment ticket via the computer network to a 
payment server which is distinct from the customer station and supplier server, 

(c) automatic verification by the payment server if the payment of the price 
is authorised for the customer, the verification being effected, according to the 

15 level of the price to be paid, either by interrogation of a customer account of the 
customer, held by the payment server and intended for payment of small sums, or 
by interrogation of a banking network, independent of the computer network, for 
payment of higher sums, 

(d) if the verification is positive, development by the payment server of a 
20 trcmsaction authorisation or voucher including at least a part of the payment ticket 

information, and 

(e) transmission of the voucher to the supplier server via the computer 
network, so as to authorise the conclusion of the purchase. 

25 2- A method as claimed in claim 1, characterised in that when a voucher is 
transmitted after verification by interrogation of a customer account held by the 
payment server, the amount of the purchase is debited from the customer account 
and credited to the supplier account of the concerned supplier and held by the 
payment server. 

30 ' 

3. A method as claimed in claim 1 or 2, characterised in that the verification 
by the payment server comprises a preliminary customer authentication phase. 

4. A method as claimed in claim 3, characterised in that the authentication is 
35 achieved by recognition of an access key transmitted by the computer network 

from the customer station to the payment server. 
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5. A method as claimed in any one of claims 1 to 4, characterised in that it 
comprises the development by the payment server of a voucher comprising at least 
a part of the information of the payment ticket and certification information. 

5 

6. A method as claimed in any one of claims 1 to 5, characterised in that it 
comprises memorisation by the payment server of the authorised transactions, by 
stocking at least a part of the contents of the voucher. 

10 7. A method as claimed in any one of claims 1 to 6, characterised in that the 
payment ticket is transmitted from the payment server to the supplier server by the 
intermediary of the customer station. 

8. A method as claimed in any one of claims 1 to 7 chcuacteriscd in that the 
15 voucher is transmitted from the payment server to the supplier server by the 

intermediary of the customer station. 

9. Electronic payment system for effecting transactions relating to the 
purchase of goods offered by suppliers to customers via a public computer 

20 network, the system comprising customer stations and supplier servers, 

characterised in that the system further comprises at least one payment 
server distinct from the customer stations and the supplier servers and comprising: 
-a front unit having means for connecting to the public network, 
-a rear unit having means for connecting to a banking network independent 
25 of the public network, 

-means for communicating between the front and rear units, 
-means for memorising customer accounts and supplier accounts, and 
-processing means for verifying, in response to the reception by the front 
unit of a transaction authorisation request or a payment ticket, concerning a 
30 purchase envisaged between the supplier and a customer, if the payment of the 
price is authorised for the customer by interrogating the customer account or the 
banking network, and, if the verification is positive, developing a transaction 
authorisation, or voucher in order to transmit the verification to the open network 
via the front unit. 



35 
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10, Payment system as claimed in claim 9, characterised in that the payment 
server comprises means for memorising authorised transactions. 
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